Communication networks now make it possible to use multiple network interfaces for sending data over several transmission paths. For example, media data may be streamed over several paths whereas before, RTP (Real Time Protocol) video streaming sessions relied on UDP (User Datagram Protocol) for sending the media stream using only one single network interface.
In the IETF (Internet Engineering Task Force) draft (referenced as “draft-singh-avtcore-mprtp-09”) the multipath transmission of an RTP (Real Time Protocol) stream consists in transmitting the RTP packets, from a sender to a receiver, over different network paths. A path is defined as a connection between one network interface of the server (the sender) and one network interface of the client (the receiver). The maximum number of paths is equal to the total number of associations between all the network interfaces of the sender and the receiver.
In order to control and monitor the transmission of the RTP packets during a communication (or media) session, RTCP (Real Time Control Protocol) packets are exchanged between the sender and the receiver. RTCP packets comprise RTCP feedback messages. RTCP feedback messages are sent regularly and comprise for instance “Receive Reports” and “Sender Reports” that make it possible to estimate the transmission conditions over the transmission paths. In case of streaming over multiple paths, the network conditions observed on each path may be different. The IETF draft thus requires RTCP feedback messages per “subflow” (i.e. per path) in addition to aggregate feedback messages that provide feedback information about the whole media session (standardized in the RTP Standard, document IETF RFC 3550).
The sender uses the information from the feedback messages in order to make distribution decisions at the expiry of a scheduling interval.
Document US 2013/0064105 A1 discloses a feedback protocol in a multiple path network wherein aggregated feedbacks are sent over any one of a plurality of paths depending on performance information (travel time, buffer occupancy) relating to at least two paths.
The inventors have brought into light several drawbacks in the prior art management of feedback in multipath communication networks.
In the IETF draft, there is no specific requirement for transmitting the RTCP messages on a specific path except for the Sender Reports and Receiver Reports (which should be both transmitted over the same path in order to ensure that the round trip time RTT is computable).
Therefore, a very straightforward solution such as randomly selecting the path over which feedback messages may be sent may lead to an inefficient session control since some feedback messages may be either lost (depending on the packet loss rate of the path) or received lately due to path transmission latency, or even discarded if the available bandwidth on the path is too low.
In document US 2013/0064105 A1, the path selection is based only on the performance of each path and not on the RTCP packet type constraints and the network path status.
Therefore, RTCP packets may be sent on inappropriate communication paths.
Thus, the inventors brought into light the fact that there is still a need for better feedback management in multipath communication networks. In particular, they brought into light a need for optimal transmission of RTCP like messages in multipath contexts.
The present invention lies within this context.